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© A distributed computer system. 


© A distributed computer system is disclosed 
which comprises a source (30) of a continuous data 
stream repetitively including data representing a dis- 
tributed computing application and a client computer 


(22), receiving the data stream, for extracting (207) 
the distributed computing application representative 
data from the data stream, and executing (224) the 
extracted distributed computing application. 
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The present invention relates to a client-server 
distributed computer system. Such a computer 
system has application in broadcast multimedia 
applications. 

Early computer systems were standalone sys- 
tems, consisting generally of mainframe comput- 
ers. Later, several mainframe computer systems 
were closely connected, or clustered, to handle 
larger computing jobs, such as a large number of 
time sharing users. With the advent of personal 
computers, large numbers of relatively low power 
standalone computer systems were controlled di- 
rectly by their users. Soon these large numbers of 
personal computers were coupled together into 
networks of computers, providing shared resources 
and communications capabilities to the users of the 
individual personal computers and between those 
users and the preexisting mainframe computers. 

One form of such a network includes a central 
computer, called a server, which generally includes 
a large amount of mass storage. Programs used by 
the network users are centrally stored in the mass 
storage on the server. When a user desires to run 
a program, the user's computer requests that a 
copy of that program be sent to it from the server. 
In response to that request, the server transfers a 
copy of the program from its mass storage to the 
main memory of the personal computer of that 
user, and the program executes on that personal 
computer. Data also may be centrally stored in the 
server and shared by all the users on the network. 
The data is stored on the mass storage of the 
server, and is accessible by all the network users 
in response to a request. The server also serves as 
a hub for communications of messages (electronic 
mail) between network users The server in such a 
system handles the storage and distribution of the 
programs, data and messages, but does not contri- 
bute any processing power to the actual computing 
tasks of any of the users. I.e. a user cannot expect 
the server computer to perform any of the process- 
ing tasks of the program executing on the personal 
computer. While such networks perform a valuable 
function, they are not distributed computing sys- 
tems, in which interconnected computers cooperate 
to perform a single computing task. 

In an improvement to such networks, the net- 
work may be configured in such a manner that a 
user on the network may request that the server, or 
other personal computer connected to the network, 
execute a program. This is termed remote execu- 
tion because a computer (server or other personal 
computer) remote from the requester is executing a 
program in response to a request from the re- 
quester. In such a system, the program of which 
remote execution is requested is either sent from 
the requester to the remote computer, or retrieved 
from the server in response to a request by the 


remote computer. When the program is received, it 
is executed. In this manner several computers may 
be enlisted to cooperate in performing a computing 
function. 

5 Recently, there have been programs which dis- 

tribute the actual computing tasks necessary for 
performing a single computing function. For exam- 
ple, in such a data base program, where the data 
base is stored in the mass storage of the server, if 

w a user desires to make a query of the data base, 
the portion of the data base management program 
on that user's personal computer will generate a 
query request, which is forwarded to the server. 
The portion of the data base management program 

75 on the server performs the query processing, e.g. 
parsing the query request, locating where the data 
specified in the query request resides on its mass 
storage device, accessing that data, and sending 
the results back to the requesting personal com- 

20 puter over the network. The portion of the data 
base management program on the personal com- 
puter then processes the data received from the 
server, e.g. formatting it, and displaying it on the 
screen or printing it on a printer. While the server 

25 is processing the query request, the personal com- 
puter is free to perform other processing, and while 
the personal computer is generating the query re- 
quest, and processing the resulting data received 
from the server, the server is free to process query 

30 requests from other personal computers. 

Other types of programs are also amenable to 
this type of distributed computing, termed client- 
server computing. The sharing of the processing 
tasks between the personal computer and the serv- 

35 er improves the overall efficiency of computing 
across the network. Such client-server computer 
systems, and remote execution networks, may be 
termed distributed computing systems because 
several computers (the server and/or the respective 

40 peripheral computers) cooperate to perform the 
computing function, e.g. data base management. 

Recently, broadcast multimedia programs, 
more specifically, interactive television (TV) pro- 
grams, have been proposed. Interactive TV pro- 

45 grams will allow a viewer of a television program to 
interact with that program. In an interactive TV 
system, the central broadcast location (TV network, 
local TV studio, cable system, etc.) will have a 
central computer, corresponding to the server corn- 
so puter, which will produce signals related to the 
interactive TV program to be broadcast simulta- 
neously with the TV (video and audio) signals. 
These signals carry data representing the inter- 
active TV program and may include commands, 

55 executable program code and/or data for control- 
ling the viewer interaction. Each viewer location will 
have a computer, corresponding to the client com- 
puter, which will receive the commands, executable 
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code and/or data from the central computer, ex- 
ecute the executable code, process the received 
data, accept input from the user and provide data 
to the user by means of the TV screen. The input 
from the user may be sent back to the computer at 
the broadcast location, allowing the user to interact 
with the interactive TV program. 

U.S. Patent 4,965,825, SIGNAL PROCESSING 
APPARATUS AND METHODS, issued Oct. 23, 
1990 to Harvey et al., describes an interactive TV 
system in which a central broadcast location in- 
cludes signals carrying commands, executable 
code and data in, for example, the vertical blanking 
interval of the television signal for receipt by the 
computer systems at the viewer locations. A com- 
puter at the viewer location extracts the commands, 
executable code and data and executes the code 
to process the data and interact with the user. Such 
a system is comparable to the remote execution 
function of distributed computer systems, de- 
scribed above, in that the viewer computer is en- 
listed into the interactive TV program, and is con- 
trolled by the central location. 

In all of the above systems, a central computer 
controls or responds to requests from peripheral 
computers attached to it through a network. I.e. the 
peripheral computer (personal computer) requests 
remote execution of a program, requests a file or 
message from, or sends a query request to, an- 
other computer. Only in response to a request 
does the other computer provide a response, e.g. 
remote execution, the requested file, message or 
retrieved data. In addition, in general, the peripheral 
computer is required to have all the resources 
necessary to completely, or almost completely, ex- 
ecute the desired program, with the server acting 
only as another storage mechanism, or at most 
sharing a portion of the computing tasks. 

The inventors herein propose a distributed 
computing system in which a server computer con- 
tinuously produces a data stream. This data stream 
acts a mass storage device for the client comput- 
ers receiving it. This data stream repetitively in- 
cludes data representing a distributed computing 
application in which the client computer may par- 
ticipate, including executable code and data. A 
transport mechanism, including a high speed, one- 
way, communication path, carries the data stream 
from the server to the client. The client receives 
the data stream, extracts the distributed computing 
representative data and executes the distributed 
computing application. 

In accordance with principles of the present 
invention, a distributed computer system comprises 
a source of a continuous data stream repetitively 
including data representing a distributed computing 
application and a client computer, receiving the 
data stream, for extracting the distributed comput- 


ing application representative data from the data 
stream, and executing the extracted distributed 
computing application. 

In a distributed computing system according to 

5 the invention, the client computer system need not 
include all the resources, in particular, main mem- 
ory and mass storage, necessary to perform the 
entire program. Instead, no mass storage is re- 
quired because the data stream provides the func- 

70 tion of the mass storage device, and the main 
memory requirement is modest because only the 
currently executing portion of the program need be 
stored in memory. When the currently executing 
portion has completed, its memory space is freed 

75 up, and the next executing portion is extracted 
from the data stream, stored in the freed memory 
space, and that portion begins execution. 

In addition, a distributed computing system ac- 
cording to the present invention allows the user of 

20 the client computer to have the option of participat- 
ing in the distributed computing task. If it is desired 
to participate, the client computer extracts the data 
representing the distributed computing application 
and executes the distributed computing application, 

25 as described above. If it is desired not to partici- 
pate, the data stream is merely ignored, and the 
processing desired by the user, or none at all, is 
performed. Such a distributed computing system 
also allows each participating client computer to 

30 join the distributed computing function at any time 
and to proceed at its own pace in performing its 
own computing function. 

A distributed computing system according to 
the present invention is particularly amenable to 

35 interactive TV applications because it allows a 
viewer to tune into an interactive TV channel at any 
time, join in the interactivity whenever desired (or 
not at all), and allows all the viewers to proceed at 
their different paces. This is especially advanta- 

40 geous in an environment when an interactive com- 
mercial, with its own executable code and data, 
may be presented within an interactive program, or 
when the viewer wishes to change channels. 

45 BRIEF DESCRIPTION OF THE DRAWING 

In the drawing: 

FIGURE 1 is a block diagram of a distributed 
computing system according to the present in- 

50 vention; 

FIGURE 2 is a block diagram of a server com- 
puter as illustrated in FIGURE 1; 
FIGURE 3 is a timing diagram illustrating the 
data streams produced by a server computer in 

55 a distributed computing system as illustrated in 
FIGURE 1; 

FIGURE 4 is a block diagram of a client com- 
puter as illustrated in FIGURE 1 . 
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FIGURE 1 is a block diagram of a distributed 
computing system according to the present inven- 
tion. In FIGURE 1, a server computer 10, which 
may include a large computer system, is coupled 
to a plurality of client computers 20 through a 
transport mechanism 30. The server computer 10 
may be coupled to more than the three client 
computers 20 illustrated in FIGURE 1 t and the 
client computers 20 may be geographically widely 
dispersed. Client computer 22 is bidirectionally 
coupled to a local computer 40, to an auxiliary data 
processing system 50 and to a central processing 
facility 60. The central processing facility 60 is 
bidirectionally coupled to the server computer 10. 
The central processing facility 60 may also be 
connected to facilities other than the server com- 
puter 10 illustrated in FIGURE 1. The local com- 
puter 40 is further bidirectionally coupled to a mass 
storage device 70. The client computer 22 interacts 
with a user 80 by providing information to the user 
via a display screen or other output device (not 
shown) and by accepting information from the user 
via a keyboard or other input device (also not 
shown). 

Client computers 24 and 26 also interact with 
their users, (not shown in order to simplify the 
drawing). In addition, client computers 24 and 26 
are bidirectionally coupled to the central process- 
ing facility 60. Such links are optional, however. 
The only requirements for any client computer 20 
is a way to interact with a user, and a connection to 
the transport mechanism 30. Links to local comput- 
ers, auxiliary data processing systems, and the 
central processing facility 60 are all optional, and 
need not be present in every one of the client 
computers 20. 

The transport mechanism 30 includes a un- 
idirectional high speed digital data link, such as a 
direct fiber optic or digital satellite link from the 
server 10 to the client computers 20. The data may 
be transported over the transport system 30 by a 
packet data system. In such a system, a stream of 
data packets, each including identification informa- 
tion indicating, among other things, the type of data 
contained in that packet and the actual data, is 
transmitted through the data link. Such a packet 
data system allows several independent streams of 
data, each identified by identification information in 
their packets, to be time multiplexed within a single 
stream of packets. 

In addition, it is possible to multiplex a plurality 
of such packet data streams over respective chan- 
nels on the same physical medium (fiber optic or 
satellite radio link) making up the transport mecha- 
nism 30. For example, different data streams may 
be modulated on carrier signals having different 
frequencies. These modulated carriers may be 
transmitted via respective transponders on a sat- 


ellite link, for example. Further, if a particular tran- 
sponder has sufficient capacity, it is possible to 
time multiplex several data streams on a single 
modulated carrier. 
5 The client computers 20 each contain a data 

receiver for selecting one of the streams of packets 
being transported over the transport mechanism 
30, receiving the selected stream of packets and 
extracting the data contained in them. Continuing 

w the above example, the data receiver may include 
a tunable demodulator for receiving one of the 
respective modulated carriers from the satellite link. 
In addition, the data receiver may include circuitry 
for time demultiplexing the respective data streams 

is being carried by that modulated carrier. 

In operation, the server 10 produces a continu- 
ous data stream in the form of a stream of packets 
for the client computers 20. The server 10 repet- 
itively inserts a packet, or successive packets, con- 

20 taining data representing the distributed computing 
application, including at least one executable code 
module, into the data stream. This code module 
contains executable code for the client computers 
20. The data receiver in, for example, client com- 

25 puter 22, continuously monitors the packets in the 
data stream on transport mechanism 30. When a 
packet including identification information indicating 
that it contains the code module (or a portion of the 
code module) required by the client computer 22 is 

30 present in the data stream, the client computer 22 
detects its presence, extracts the code module (or 
the portion of the code module) from that packet 
and stores it in the main memory. When the code 
module is completely received, the client computer 

35 22 begins to execute it. 

There may be more than one code module 
placed in the continuous data stream, each contain- 
ing a different portion of the distributed computing 
application. For example, it is possible to divide the 

40 distributed computing application into small por- 
tions in such a manner that only one portion at a 
time need be executed at a time. The portion of 
the distributed computing application currently 
needed to execute is loaded into the memory of 

45 the client computer 22. When that portion has 
completed its execution, then a code module con- 
taining the executable code for the next portion of 
the distributed computing application is extracted 
from the data stream, stored in memory and ex- 

50 ecuted. Each portion is extracted from the data 
stream as needed. If there is sufficient memory in 
the client computer 22, it is possible to load several 
code modules into the memory and switch be- 
tween them, without extracting them from the data 

55 flow, but this is not necessary. By structuring a 
distributed computing application in this manner, 
the required memory size of the client computer 22 
may be minimized 
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The server 10 may also repetitively include a 
packet or packets containing one or more data 
modules in the data stream. The data modules 
contain data to be processed by the executable 
code in the code module. Prior to t or during the 
execution of the code from a previously extracted 
code module, the client computer 22 may require 
access to the data in the data module or modules, 
if so, the client computer 22 monitors the data 
stream for the required data module or modules. 
When packets containing the data module or mod- 
ules (or portions of the data module or modules) 
are present in the data stream, they are extracted, 
and the contents stored in the main memory of the 
client computer 22. When all the required data 
modules have been completely received, the client 
computer 22 begins or continues execution of the 
code from the code module to process the data 
from the received data module or modules. As is 
the case for code modules, it is possible for more 
than one data module to be stored in memory, if 
there is sufficient memory in client computer 22. 

The server 10 may further repetitively include 
in the data stream a packet or packets containing a 
directory of the code and data modules currently 
being included in the data stream. The directory 
includes a list of all the code and data modules 
which are present in the data stream, along with 
information about those modules. If a directory is 
present in the data stream, then, prior to extraction 
of any code or data modules from the data stream, 
the client computer 22 monitors the data stream for 
the directory. When packets containing the direc- 
tory (or portions of the directory) are present in the 
data stream, they are extracted, and their data 
stored in the main memory of the client computer 
22. When the directory has been completely re- 
ceived, the client computer 22 evaluates the entries 
in the directory, then requests the first code and/or 
data module from the data stream and execution 
proceeds as described above. 

Any of the client computers 20 may join the 
distributed computing function represented by the 
packet stream at any time, and each of the client 
computers 20 may operate at its own speed, gen- 
erally in response to the user 80. In order to allow 
for this, the server 10 repetitively places the direc- 
tory and all the code and data modules which the 
client computers 20 may require to perform their 
portion of the distributed computing function into 
the data stream on the transport mechanism 30. 
Whenever one of the client computers 20 joins the 
distributed computing function, it monitors the new- 
ly selected packet stream on the transport mecha- 
nism 30 for the directory module, extracts it, and 
processes it as described above. During execution, 
whenever one of the client computers 20 requires 
the a new code and/or data module, it monitors the 


data stream on the transport mechanism 30 for the 
newly required code and/or data module, extracts it 
and either executes it, if it is a code module, or 
processes it if it is a data module, as described 
5 above. 

The packet data stream may also include pack- 
ets of auxiliary data. This data is not required by 
the client computer 22 for execution of the code, 
although it may be related to the execution be- 

/o cause the user 80 may interact with the executing 
program on the client computer 22 based on re- 
ceived auxiliary data. The data stream receiver in 
the client computer 22 recognizes the auxiliary 
data packets in the data stream on the transport 

75 mechanism 30 and passes them directly to the 
auxiliary data processor 50. The auxiliary data pro- 
cessor 50 processes its packets independently of 
the client computer 22. If the auxiliary data must be 
presented to the user 80, the auxiliary data proces- 

20 sor 50 may provide its own display device (not 
shown) which may be shared with the client com- 
puter 22, or the display device (not shown) asso- 
ciated with the client computer 22 may be shared 
with the auxiliary data processor 50, to provide a 

25 single information display to the user 80. The auxil- 
iary data processor 50 may have links to other 
illustrated elements (not shown), but that is depen- 
dent upon the type of data. 

In an interactive TV system, for example, the 

30 auxiliary data includes the video and audio portions 
of the underlying television signal. For example, the 
auxiliary data would include video packets contain- 
ing MPEG, or MPEG-like, encoded data represent- 
ing the television image and audio packets contain- 

35 ing digitally encoded audio. Further, there may 
possibly be several different audio packet streams 
carrying respective audio channels for stereo, sec- 
ond audio program (SAP) or multilanguage capabil- 
ity. In an auxiliary data processor 50 in such a 

40 system, the video packets would be supplied to a 
known MPEG (or similar) decoder (not shown) 
which would generate standard video signals, 
which would be supplied to a television receiver or 
video monitor (not shown). The audio packets 

45 would be supplied to a known audio decoder (not 
shown) which would generate standard audio sig- 
nals for the television receiver or speakers (not 
shown). 

In such an interactive TV system, the client 
so computer 22 may, in response to execution of the 
executable code module, generate graphic displays 
to supply information to the user 80. These graphic 
displays may be combined with the standard video 
signal from the MPEG decoder in a known manner, 
55 and the combined image displayed on the televi- 
sion receiver or video monitor. The client computer 
22 may also generate sounds to provide other 
information to the viewer. The generated sounds 
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may be combined, in known manner, with the stan- 
dard audio signals from the audio decoder, and the 
combined sound played through the television re- 
ceiver or speakers. 

Furthermore, time code data may be included 
in either or both of the television auxiliary packet 
data stream and the packet data stream represent- 
ing the interactive TV application. This permits 
synchronization of any graphic images or sounds 
generated by the client computer 22 with the televi- 
sion signal from the auxiliary data. In this case, the 
client computer 22 would have access to the time 
code data, and would control the generation of the 
graphic image and/or sound to occur at the desired 
time, as supplied by the time code data. 

In such an interactive TV system, both the 
client computer 22 and the auxiliary data processor 
50 may be contained in a single enclosure, such as 
a television receiver, or television set-top decoder 
box. A television receiver, or decoder box would 
include connectors for attaching to a local com- 
puter or other equipment. 

The user 80 provides input to the program 
running on the client computer 22 during its execu- 
tion. This data may be required by the server 1 0 in 
order to effect the distributed computing function. 
In an interactive TV system, for example, user 80 
may provide input to the client computer through a 
handheld remote control unit. 

The user data is transferred to the server com- 
puter 10 via the central processing facility 60. In 
one embodiment, data is sent from the client com- 
puters 20 to the server computer 10 via modems 
through the telephone system acting as the central 
processing facility 60. The server computer 10 
receives and processes the data received from the 
client computers 20 during execution of its portion 
of the distributed computing function. 

Server computer 10 may generate new, or 
modify existing, code and/or data modules in the 
data stream on the transport mechanism 30, in a 
manner described below, based on that received 
data. Alternatively, the server computer 10 may 
immediately return information to the client com- 
puters 20 in the other direction through the central 
processing facility 60. The information in newly 
generated code and/or data modules is processed 
by all client computers 20 participating in the dis- 
tributed computing function, while information 
passed from the server computer 10 to the client 
computers 20 through the central processing fa- 
cility 60 is specifically related to the client com- 
puter (22, 24, 26) to which that information was 
sent 

In another embodiment, the central processing 
facility 60 may include its own computer system, 
separately connected by modem to both the client 
computers 20 and the server computer 10 through 


the telephone system. In either of the above em- 
bodiments, the central computing facility 60 pro- 
vides access to other computers or processing 
facilities (not shown) via the telephone system. 
5 Thus, if information from other computer systems 
is needed to perform the distributed computing 
function, those computer systems may be acces- 
sed via modem through the telephone system by 
either the client computers 20 or the server com- 

ro puter 10. 

An input/output (I/O) port on the client com- 
puter 22 is coupled to a corresponding port on the 
local computer 40. Local computer 40 is collocated 
with the client computer 22. Local computer 40 

75 may be a personal computer used by the user 80 
of the client computer 22, or may be a larger 
computer, or computer network located at the 
same site as the client computer 22. This allows 
the client computer 22 to access data on the at- 

20 tached mass storage 70 of the personal computer 
or a computer on the network located at the client 
computer 22 site. In addition, the client computer 
22 may use the mass storage 70 of the local 
computer 40 for storage of data to be retrieved 

25 later. It is likely that the local computer 40 will 
include both an output device (not shown) such as 
a computer monitor and an input device (also not 
shown) such as a computer keyboard. Both of 
these may be shared with the client computer 22 

30 and/or the auxiliary data processor 50, as de- 
scribed above. 

For example, the distributed computing system 
illustrated in Figure 1 may be part of a widespread 
corporate computing system, and the server 10 

35 may be located at a central location of that cor- 
poration. The client computer 22 may be located at 
a remote location, and the local computer 40 may 
be coupled to the personal computer network at 
that location. Workers at that location may store 

40 shared data (e.g. financial information) on the serv- 
er connected to that network. The distributed com- 
puting function may include gathering local finan- 
cial data from the client computers at the remote 
locations, processing that financial data and return- 

45 ing overall financial results to the client computers. 
In such an application, the executable code ex- 
ecuted on the client computer 22 accesses the 
data from the local computer 40 (either from its 
attached mass storage 70 or through the network) 

so through the I/O port, and sends it to the server 
computer 10 through the central processing facility 
60. The server computer 10 continues its process- 
ing based on the information received from client 
computer 22 (and other client computers 20), and 

55 returns the results of that processing to the client 
computers 20 either through the central processing 
facility 60 or via the data stream on the transport 
mechanism 30. 
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In another example, the distributed computing 
system may be an interactive television system, 
broadcasting a home shopping show as the distrib- 
uted computing application. In such a case, the 
auxiliary data carries the video and audio portion of 
the television signal, which may show and describe 
the items being offered for sale, and may include 
both live actors and overlaid graphics generated at 
the central studio. Code and data modules making 
up the interactive television application may include 
data about the products which will be offered for 
sale during this show, or portion of the show, and 
executable code to interact with the user in the 
manner described below. 

When a viewer wishes to order an item, a 
button is pressed on the TV remote control. This 
button signals the client computer 22 to display a 
series of instructions and menus necessary to so- 
licit the information necessary to place the order, 
e.g. the item number, name and address of the 
viewer, the method of payment, the credit card 
number (if needed), etc. These instructions are 
generated in the client computer as graphics which 
are overlaid on the television video image. It is also 
possible for a computer generated voice to be 
generated and combined with the television audio 
either by voice-over, or by replacing the television 
audio. The viewer responds to the instruction by 
providing the requested information via the TV re- 
mote control. When the information requested by 
the on-screen display and/or voice instructions has 
been entered by the viewer, it is sent to a central 
computer via the modem in the client computer. An 
order confirmation may be sent in the other direc- 
tion from the central computer. 

It is also possible that permanent information 
about the viewer (i.e. the name, address, method of 
payment and credit card number) may be preen- 
tered once by the viewer, so it is not necessary to 
solicit that information each time an order is 
placed. The information is stored in permanent 
memory in the client computer. In such a case, 
when an order is placed, that information is re- 
trieved from the permanent memory, appended to 
the item number and transmitted to the central 
computer. It is further possible that, by means of 
time codes, or other commands, inserted into the 
data stream, the client computer will know which 
item is currently being offered for sale. In such a 
case, the viewer will be able to order it by simply 
pressing one button on the TV remote control. In 
response, the client computer can combine the 
previously received information related to the item 
currently being offered for sale with the previously 
stored personal information related to the viewer, 
and transmit the order to the central computer and 
receive the confirmation in return. 


Because the code and data modules related to 
the home shopping program are repetitively in- 
serted into the data stream, a viewer may tune into 
the program at any time and be able to participate 
5 interactively. Similarly, it is not necessary for the 
viewer to participate interactively, but may simply 
ignore the interactive portion of the show. 

It is also possible for the client computer 22 to 
receive control information from the local computer 

w 40. For example, the user 80, using the local com- 
puter 40, could control the client computer 22 via 
the I/O port to select a desired one of the data 
streams on transport mechanism 30, and process 
the program currently being broadcast on that data 

75 stream, with interaction with the user 80 through 
the input and output devices (not shown) con- 
nected to the local computer 40. 

It is further possible for the user 80 to cause 
the client computer 22 to access the server com- 

20 puter 10 through the central processing facility 60, 
instead of via the data stream on transport mecha- 
nism 30, and receive code and data modules via 
this bidirectional link. 

FIGURE 2 is a block diagram illustrating a 

25 server computer 10 as illustrated in FIGURE 1. In 
FIGURE 2, a source of distributed computing ap- 
plication code and data 101 includes an application 
compiler, and software management module (not 
shown) and has an output terminal coupled to an 

30 input terminal of a flow builder 102. An output 
terminal of flow builder 102 is coupled to an input 
terminal of a transport packetizer 104. An output 
terminal of transport packetizer 104 is coupled to a 
first input terminal of a packet multiplexer 106. An 

35 output terminal of packet multiplexer 106 is coup- 
led to an input terminal of a transport multiplexer 
110. An output terminal of transport multiplexer 110 
is coupled to the physical medium making up the 
transport mechanism 30 (of FIGURE 1). A second 

40 input terminal of packet multiplexer 106 is coupled 
to a source of auxiliary data packets 107. A clock 
109 has respective output terminals coupled to 
corresponding input terminals of the transport pac- 
ketizer 104 and auxiliary data source 107. A data 

45 transceiver 103 has an first bidirectional terminal 
coupled to the central processing facility 60 (of 
FIGURE 1) and a second bidirectional data coupled 
to the application code and data source 101. 

Application code and data source 101, flow 

50 builder 102, transport packetizer 104, auxiliary data 
source 107, clock 109 and packet multiplexer 106, 
in combination, form a channel source 108 for the 
transport mechanism, illustrated by a dashed box 
in . Other channel sources, including similar com- 

55 ponents as those illustrated in channel source 108 
but not shown in FIGURE 1, are represented by 
another dashed box 1 08a. The other channel sour- 
ces (108a) have output terminals coupled to other 
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input terminals of the transport multiplexer 110, and 
may have input terminals coupled to central pro- 
cessing facilities through data transceivers. 

In operation, data representing the distributed 
computing application program, and data related to 
the transmission of the program over the transport 
mechanism 30 are supplied to the flow builder 102 
from the application source 101. This data may be 
supplied either in the form of files containing data 
representing the code and data modules, or by 
scripts providing information on how to construct 
the code and data modules, or other such informa- 
tion. The code and data modules may be constant 
or may change dynamically, based on inputs re- 
ceived from the client computers 20 via the central 
computing facility 60 and/or other sources. The 
executable code and data module files may be 
generated by a compiler, interpreter or assembler 
in a known manner in response to source language 
programming by an application programmer. The 
data file related to the transmission of the modules 
includes such information as: the desired repetition 
rates for the directory and the code and data 
modules to be included in the data stream; the size 
of main memory in the client computers 20 re- 
quired to store each module, and to completely 
execute the application program; a priority level for 
the module, if it is a code module, etc. 

Flow builder 102 processes the data from the 
application source 101. In response, flow builder 
102 constructs a directory module, giving an over- 
all picture of the application program. The informa- 
tion in the directory module includes e.g. the iden- 
tification of all the code and data modules being 
repetitively transmitted in the data stream, their 
size and possibly other information related to those 
modules. Then the application program representa- 
tive data is processed to generate the code and 
data modules. The directory, code and data mod- 
ules thus constructed are formatted by adding 
module headers and error detection and/or correc- 
tion codes to each module. A transmission sched- 
ule is also generated. After this processing is com- 
plete, the data representing the directory module 
and the code and data modules are repetitively 
presented to the transport packetizer 1 04 according 
to the schedule previously generated. 

The transport packetizer 104 generates a 
stream of packets representing the directory mod- 
ule and the code and data modules as they are 
emitted from the flow builder 102. Each packet has 
a constant predetermined length, and is generated 
by dividing the data stream from the flow builder 
into groups of bits, and adding a packet header 
with information identifying the information con- 
tained in the packet, and an error detection and/or 
correction code, etc., to each group, such that each 
packet is the same predetermined length. (If there 


is insufficient data from the flow builder 102 to 
completely fill a packet, the packet is padded with 
null data.) These packets are time multiplexed with 
the auxiliary data packets, in a known manner, to 

5 form a single packet stream in the packet mul- 
tiplexer 106. It is also possible for the generated 
packets to have varying lengths. In this case, the 
packet header for each packet will contain the 
length of that packet. In addition, time code data 

10 packets are placed in the data stream packets 
and/or the auxiliary data packets based on data 
received from the clock 109. 

Packet streams from all of the channel sources 
(108,108a) are multiplexed into a single transport 

;s channel, which is transmitted through transport 
mechanism 30. As described above, the packet 
streams may be frequency multiplexed by having 
each packet stream modulate a carrier signal at a 
different frequency, with all of the carriers being 

20 carried by a satellite link to the client computers 
20, in a known manner. In addition, if there is 
sufficient capacity within one carrier channel, sev- 
eral packet streams may be statistically time mul- 
tiplexed, and used to modulate a single carrier, 

25 also in a known manner. For example, it has been 
proposed to time multiples up to eight interactive 
television data streams through a single satellite 
link. 

Data from the client computers 20 via the cen- 

30 tral processing facility 60 (of FIGURE 1) is received 
at the server computer 10 by the data transceiver 
103, which may include its own processor (not 
shown). If an immediate response is generated, the 
transceiver 103 processor returns that response via 

35 the central processing facility 60 to a specific client 
computer (22-26), a specific set of the client com- 
puters 20 or to all client computers 20 in their turn. 
If, however, a common response to all client com- 
puters 20 is desired, the application programmer 

40 may amend the code and data files in the applica- 
tion code and data source 101 using the applica- 
tion compiler. These amended files are then pro- 
cessed by the flow builder again to generate an- 
other flow. It is further possible that the code and 

45 data files in the application source 101 may be 
amended automatically and dynamically (i.e. in real 
time) in response to data received from the tran- 
sceiver 103, and the flow updated as the data is 
being received from the client computers 20. 

so FIGURE 3 is a timing diagram illustrating the 

data streams produced by the server computer 10 
in a distributed computing system as illustrated in 
FIGURE 1. In FIGURE 3 server computer 10 is 
shown as simultaneously producing a plurality of 

55 packet streams 32-38. Each packet stream (32-38) 
is shown as a horizontal band divided into packets 
having the same duration and number of bits. As 
described above, it is possible that the size of the 
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packets within any packet stream vary with the 
amount of data to be carried. In FIGURE 3 it can 
be seen that the starting times of the packets are 
not synchronized. It is possible to synchronize the 
packets, but it in not necessary. In FIGURE 3. 
packets carrying data representing directories are 
designated DIR. packets carrying data representing 
code modules are designated CM, packets carrying 
data representing data modules are designated 
DM, and packets carrying auxiliary data are des- 
ignated AUX. 

In the top series of packets 32, the leftmost 
packet contains data representing a code module, 
CM. This is followed by three packets containing 
auxiliary data, AUX, followed by another packet 
containing data representing the code module, CM. 
From the series of packets 32 it can be seen that 
the code module is repetitively produced. There 
may be more or fewer packets in between succes- 
sive repetitions of the code module packets CM. 
The rate of repetition may be specified by the 
programmer when the application is programmed, 
and may be varied during the execution of the 
application. 

In the next series of packets 34, the leftmost 
packet contains auxiliary data, AUX. The next two 
packets contain respective portions of a code mod- 
ule (CM1.CM2). The last packet contains auxiliary 
data, AUX. From the series of packets 34 it can be 
seen that if a code module is too large to be 
contained in a single packet, it may be carried by 
more than one, with each packet containing a por- 
tion of the code module. Although two packets are 
illustrated in the series of packets 34 as containing 
the code module (CM1,CM2), any number of pack- 
ets may be used to carry the code module, de- 
pending upon its size. The two packets carrying 
the code module, (CM1.CM2) are repetitively trans- 
mitted (not shown) in the series of packets 34, as 
described above. 

In the series of packets 36, the leftmost packet 
contains data representing a code module (CM). 
The next packet (DM1) is a first packet containing 
data representing a data module. The next packet 
contains auxiliary data, AUX. The next packet 
(DM2) is a second packet containing the remaining 
data representing the data module. From the series 
of packets 36 it may be seen that a data module 
(DM1, DM2), associated with the code module 
(CM), may also be included in the packet stream. 
Both the code module (CM) and the data module 
(DM1, DM2) are repetitively transmitted (not shown) 
in the series of packets 36. The rate of repetition of 
the code module (CM) may be different from that 
of the data module (DM1, DM2), and both rates may 
be specified by the application programmer and 
varied during the execution of the application. 


It may further be seen that if the data module 
is too large to be contained in a single packet, it 
may be carried by more than one packet, with 
each packet containing a portion of the data mod- 

5 ule. Although two packets are illustrated in the 
series of packets 36 as containing the data module 
(DM1, DM2), any number of packets may be used 
to carry the data module, depending upon its size. 
It may be further seen that the packets carrying the 

70 data module need not be transmitted sequentially, 
but may have intervening packets in the packet 
stream. The same is true for multiple packets car- 
rying a code module or directory module (not 
shown). 

is In the bottommost series of packets 38, the 
leftmost packet contains data representing the di- 
rectory (DIR). The next packet contains data repre- 
senting a code module (CM), followed by a packet 
containing auxiliary data (AUX) and a packet con- 

20 taining data representing . a data module (DM). In 
the series of packet 38 all of a directory module 
(DIR), a code module (CM) and a data module 
(DM) in a single packet stream may be seen. The 
respective repetition rates of these three modules 

25 may be different, as specified by the programmer 
of the application, and may be varied during the 
execution of the application. 

FIGURE 4 is a block diagram of a client com- 
puter 22 as illustrated in FIGURE 1. In FIGURE 4, 

30 transport mechanism 30 (of FIGURE 1) is coupled 
to an input terminal of a stream selector 202. An 
output terminal of stream selector 202 is coupled to 
respective input terminals of an auxiliary data ex- 
tractor 204 and a packet data extractor 206. An 

35 output terminal of auxiliary data extractor 204 is 
coupled to the auxiliary data processor 50 (of FIG- 
URE 1). A bidirectional terminal of packet data 
extractor 206 is coupled to a corresponding termi- 
nal of a stream I/O adapter 208. A control output 

40 terminal of stream I/O adapter 208 is coupled to a 
corresponding control input terminal of stream se- 
lector 202. The combination of stream selector 202, 
auxiliary data extractor 204 and packet data extrac- 
tor 206 form a data stream receiver 207 for client 

45 computer 22, illustrated by a dashed line in FIG- 
URE 4. 

Stream I/O adapter 208 forms a part of a 
processing unit 224 in client computer 22, illus- 
trated by a dashed line in FIGURE 4. In addition to 

so the stream I/O adapter 208, processing unit 224 
includes a processor 210, read/write memory 
(RAM) 212 and read-only memory (ROM) 214 
coupled together in a known manner via a system 
bus 216. Further input and output facilities are 

55 provided by an I/O port 218, coupled to the local 
processor 40 (of FIGURE 1); user I/O adapter 220, 
for communicating with user 80; and modem 222, 
coupled to the central processing facility 60 (of 
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FIGURE 1); all also coupled to the system bus 216 
in a known manner. Other adapters (not shown) 
may be coupled to system bus 216 to provide 
other capabilities to the processing unit 224. 

As described above, auxiliary data extractor 
204, I/O port 218 and modem 222 are not required 
in a client computer 20 according to the present 
invention. They are illustrated in FIGURE 1 and 
FIGURE 4 to show optional additional functionality. 

In operation, processor 210 of processing unit 
224 retrieves program instructions permanently 
stored in ROM 214, or temporarily stored in RAM 
212, and executes the retrieved instructions to read 
data from ROM 212 and/or RAM 214, write data to 
RAM 212 and/or receive data from or supply data 
to outside sources via the I/O port 218, user I/O 
adapter 220 and/or modem 222, in a known man- 
ner. Under program control, processor 210 may 
also request a code and/or data module from the 
data stream supplied to the client computer 22 via 
the transport mechanism 30 (of FIGURE 1). To 
retrieve this data, processor 210 first instructs 
stream I/O adapter 208 to send a selection control 
signal to the stream selector 202, possibly in re- 
sponse to user input from user I/O adapter 220. 
Then processor 210 issues a request for a specific 
code or data module to the stream I/O adapter 208. 
Stream I/O adapter 208 relays this request to the 
packet data extractor 204. 

Transport mechanism 30 (of FIGURE 1) sup- 
plies all of the plurality of packet streams (32-38 of 
Figure 3) it carries to the stream selector 202, 
which passes only the selected packet stream. 
Auxiliary data extractor 204 monitors the selected 
packet stream, extracts the auxiliary data packets 
from it and supplies them directly to the auxiliary 
data processor 50 (of FIGURE 1). Packet data 
extractor 206 similarly monitors the selected packet 
stream, extracts the directory, code and/or data 
module packets requested by the stream I/O adapt- 
er 208 and supplies them to the stream I/O adapter 
208. The data in the packets returned to the stream 
I/O adapter 208 is supplied to the RAM 212. When 
the entire module has been retrieved from the 
packet stream (which may require several packets, 
as described above), processor 210 is notified of 
its receipt by the stream I/O adapter 208. Proces- 
sor 210 may then continue execution of its pro- 
gram. 

The data stream in a distributed computing 
system illustrated in FIGURE 1 is similar to a mass 
storage system in prior art systems. An application 
program executing on the processor 210 makes a 
request for a module listed in the directory in the 
same manner that such a program would make a 
request for a file containing a code or data module 
previously stored on a mass storage device in a 
prior art system. The data stream receiver 207 is 


similar to a mass storage device, and stream I/O 
208 acts in a similar manner to a mass storage 
adapter on a prior art system by locating the de- 
sired data, transferring it to a predetermined loca* 

5 tion (I/O buffer) in the system memory and inform- 
ing the processor of the completion of the retrieval. 
However, the stream I/O adapter 208 can only 
retrieve code and data from the data stream; data 
cannot be written to the data stream. 

70 As described above, the distributed computing 
application may be divided into more than one 
code module, each containing executable code for 
a different portion of the distributed computing ap- 
plication. When a particular code module is de- 

15 sired, processor 210 requests that code module 
from stream I/O adapter 208. When execution of 
that module has completed, processor 210 re- 
quests the next module from stream I/O 208. Be- 
cause code and data modules are repetitively car- 

20 ried on the data stream, a module may be deleted 
from RAM 212 when it is not currently needed 
without the necessity of temporarily being stored, 
because if it is required later, it may again be 
retrieved from the data stream when needed. How- 

25 ever, if RAM 212 has sufficient capacity, processor 
210 may request stream I/O adapter to simulta- 
neously load several code modules into RAM 212. 
If this can be done, then processor 210 may switch 
between code modules without waiting for stream 

30 I/O adapter 208 to extract them from the data 
stream. 

As described above, other I/O adapters may be 
coupled to the system bus 216 in a known manner. 
For example, in an interactive TV system, a graph- 

35 jcs adapter may be coupled to system bus 216. 
The graphics adapter generates signals represent- 
ing graphical images, in a known manner, in re- 
sponse to instructions from the processor 210. Fur- 
ther, these signals may be combined with the stan- 

40 dard video signal produced by the video decoder 
(described above) in the auxiliary data processor 
50 of an interactive TV system. When the graphical 
image representative signal and the standard video 
signal are combined, the resulting signal represents 

45 an image in which the image generated by the 
graphics adapter is superimposed on the image 
represented by the broadcast video signal. It is 
also possible to selectively combine these two im- 
age representative signals under the control of the 

so processor 21 0. 

An interactive TV system, may also include a 
sound adapter coupled to the system bus 216. The 
sound adapter generates a signal representing a 
computer generated sound (such as music, syn- 

55 thesized voice or other sound), in a known manner, 
in response to instructions from the processor 210. 
Further, these signals may be combined with the 
standard audio signal produced by the audio de- 
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coder (described above) in the auxiliary data pro- 
cessor 50 of an interactive TV system. When the 
sound representative signal and the standard audio 
signal are combined, the resulting signal represents 
the combination of the sound generated by the 
sound adapter and the broadcast audio signal. It is 
also possible to selectively combine these two 
sound representative signals under the control of 
the processor 210. 

The timing of the generation and display of the 
graphical image and sound representative signals, 
may be controlled by receipt of the time code data 
from the data stream. This enables an executable 
code module to synchronize the display of proces- 
sor generated image and presentation of processor 
generated sound to the broadcast video and audio. 
It is further possible to synchronize the operation of 
the interactive TV application by the insertion of 
specialized packets into the data stream which 
cause an interrupt of the code currently executing 
in processor 210. Stream I/O 208 monitors the data 
stream for such specialized packets, and generates 
an interrupt, in a known manner, for the processor 
210. Processor 210 responds to that interrupt, also 
in known manner, by executing an interrupt service 
routine (ISR). This ISR may be used for synchro- 
nization of the interactive TV application, or other 
purposes. 

A client computer 22 in a distributed computing 
system as illustrated in FIGURE 1 does not need a 
mass storage device, nor a large amount of RAM 
212. Such a system decreases the cost of a client 
computer, and increases the functionality of the 
lower cost client computers. In addition, such a 
client computer has the option of participating in a 
distributed computing function, may join in the dis- 
tributed computing function at any time (or may 
drop out and return later), and may participate at 
its own pace. 

Claims 

1. A distributed computer system characterized 
by: 

a source (10) of a continuous data stream 
repetitively including data representing a dis- 
tributed computing application; and 

a client computer (20), receiving (207) the 
data stream, extracting (206) the distributed 
computing application representative data from 
the data stream, and executing (224) the ex- 
tracted distributed computing application. 

2. The computer system of claim 1 , further char- 
acterized by an auxiliary data processor; 
wherein: 

the data stream source produces the data 
stream further including auxiliary data; and 


the client computer extracts the auxiliary 
data from the data stream and supplies it to 
the auxiliary data processor. 

5 3. The computer system of claim 2, characterized 
in that: 

the data stream source produces the data 
stream in the form of a series of packets; 

a first one of the series of packets contains 

io data representing the distributed computing 
application and includes identification informa- 
tion indicating that the first one of the series of 
packets contains data representing the distrib- 
uted computing application; and 

75 a second one of the series of packets 

contains auxiliary data and includes identifica- 
tion information indicating that the second one 
of the series of packets contains auxiliary data. 

20 4. The computer system of claim 1 , characterized 
in that: 

the data stream source simultaneously 
produces a plurality of continuous data 
streams, each repetitively including data repre- 

25 senting a respective distributed computing ap- 

plication; and 

the client computer further includes a data 
receiver for selectively receiving one of the 
plurality of data streams, and extracting the 

30 distributed computing application representa- 

tive data included in the selected one of the 
data streams, 

5. The computer system of claim 4, further char- 
35 acterized by an auxiliary data processor; 

wherein: 

the data stream source produces the data 
stream further including auxiliary data; and 

the client computer extracts the auxiliary 
40 data from the data stream and supplies it to 

the auxiliary data processor. 

6. The computer system of claim 4, characterized 
in that: 

45 the data stream source produces the data 

stream in the form of a series of packets; 

a first one of the series of packets contains 
data representing the executable code module 
and includes identification information indicat- 

50 ing that the first one of the series of packets 

contains data representing the executable code 
module; 

a second one of the series of packets 
contains data representing the data module 
55 and includes identification information indicat- 

ing that the second one of the series of pack- 
ets contains data representing the data mod- 
ule; and 
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a third one of the series of packets con- 
tains auxiliary data and includes identification 
information indicating that the third one of the 
series of packets contains auxiliary data. 

5 

7. The computer system of claim 6, characterized 
in that: 

the data stream source produces the data 
stream further including a directory module 
containing information related to the code w 
module; and 

the client computer first extracts the direc- 
tory module from the data stream, then ex- 
tracts the code module in response to the 
information related to the code module in the 15 
extracted directory module, and executes the 
extracted code module. 

8. The computer system of claim 1, characterized 

in that: 20 

the data stream source produces the data 
stream in the form of a series of packets; 

a first one of the series of packets contains 
data representing the executable code module 
and includes identification information indicat- 25 
ing that the first one of the series of packets 
contains data representing the executable code 
module; 

a second one of the series of packets 
contains data representing the data module 30 
and includes identification information indicat- 
ing that the second one of the series of pack- 
ets contains data representing the data mod- 
ule; 

a third one of the series of packets con- 35 
tains data representing the directory module 
and includes identification information indicat- 
ing that the second one of the series of pack- 
ets contains data representing the directory 
module; and 40 

a fourth one of the series of packets con- 
tains auxiliary data and includes identification 
information indicating that the third one of the 
series of packets contains auxiliary data. 

45 

9. The computer system of claim 8, characterized 
in that: 

the data stream source produces the data 
stream further including a data module and a 
directory module further contains information 50 
related to the data module; and 

the client computer further extracts the 
data module from the data stream in response 
to the information related to the data module in 
the extracted directory module and executes 55 
the extracted code module to process the ex- 
tracted data module. 


10. In a distributed computer system, a client com- 
puter (22), characterized by: 

an input terminal (30), for receiving a con- 
tinuous data stream repetitively including data 
representing a distributed computing applica- 
tion 

a data stream receiver (207), coupled to 
the input terminal, for receiving the data 
stream and extracting (206) the distributed 
computing application representative data; and 

a processing unit (224), coupled to the 
data stream receiver, for receiving and execut- 
ing (210) the distributed computing application. 

11. The client computer of claim 10, characterized 
in that the processing unit comprises: 

a system bus; 

read/write memory, coupled to the system 

bus; 

a data stream input/output adapter, coup- 
led between the data stream receiver and the 
system bus, for receiving the extracted distrib- 
uted computing application representative data 
from the data stream receiver, and storing it in 
the read/write memory; and 

a processor, coupled to the system bus for 
executing the distributed computing application 
stored in the read/write memory. 

12. The client computer of claim 10, characterized 
in that: 

the input terminal receives the data stream 
as a series of packets containing packets car- 
rying the distributed computing application re- 
presentative data; and 

the data stream receiver comprises a 
packet data extractor, coupled to the input 
terminal, for extracting the packets carrying the 
distributed computing application representa- 
tive data. 

13. The client computer of claim 12, characterized 
in that: 

the series of packets in the data stream 
further include packets carrying auxiliary data; 

the client computer further includes an 
auxiliary data processor; and 

the data stream receiver comprises an 
auxiliary data packet extractor, coupled to the 
auxiliary data processor, for extracting the 
packets carrying the auxiliary data from the 
data stream and supplying them to the auxil- 
iary data processor. 

14. The client computer of claim 13, characterized 
in that the distributed computing system is an 
interactive television system, and the auxiliary 
data is television video and audio. 
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15. The client computer of claim 10, characterized 
in that: 

the input terminal receives a plurality of 
data streams, each including data representing 
a respective distributed computing application; 
and 

the data stream receiver comprises: 
a data stream selector, coupled to the in- 
put terminal, for producing a selected one of 
the plurality of data streams in response to 
control signals from the processing unit; and 

a distributed computing representative 
data extractor, coupled between the data 
stream selector and the processing unit, for 
extracting the distributed computing application 
representative data from the selected one of 
the plurality of data streams. 

16. The client computer of claim 15, characterized 
in that: 

the data stream selector comprises a se- 
lection control input terminal, and produces the 
selected one of the plurality of data streams in 
response to a control signal at the selection 
control input terminal; 

the processing unit comprises: 

a system bus; 

read/write memory, coupled to the system 

bus; 

a data stream input/output adapter, coup- 
led between the data stream receiver and the 
system bus, for receiving the extracted distrib- 
uted computing application representative data 
from the data stream receiver, and storing it in 
the read/write memory, and having a control 
output terminal coupled to the selection control 
input terminal of the data stream selector, for 
producing the selection control signal; and 

a processor, coupled to the system bus, 
for controlling the data stream input/output de- 
vice to generate a selection control signal se- 
lecting a specified one of the plurality of data 
streams, and for executing the distributed 
computing application stored in the read/write 
memory. 

17. The client computer of claim 10, characterized 
in that: 

the input terminal receives the distributed 
computing application representative data in- 
cluding an executable code module; 

the data stream receiver extracts the ex- 
ecutable code module; and 

the processing unit executes the extracted 
code module. 

18. The client computer of claim 17, characterized 
in that: 


the input terminal receives the distributed 
computing application representative data fur- 
ther includes a directory module containing 
information related to the executable code 
5 module; and 

the data stream receiver first extracts the 
directory module from the data stream; 

the processing unit then processes the in- 
formation related to the executable code mod- 
w ule in the directory module; 

the data stream receiver then extracts the 
executable code module from the data stream 
based on the information related to the execut- 
able code module in the extracted directory 
is module; and 

the processing unit then executes the ex- 
tracted executable code module. 

19. The client computer of claim 18, characterized 
20 in that: 

the distributed computing application re- 
presentative data further includes a data mod- 
ule and the directory module further contains 
information related to the data module; 
25 the processing unit further processes the 

information related to the data module in the 
directory module; 

the data stream receiver further extracts 
the data module from the data stream based 
30 on the information related to the data module 

in the extracted directory module; and 

the processing unit executes the extracted 
code module to process the extracted data. 

35 20. The client computer of claim 10 characterized 
in that the distributed computing application is 
divided into a plurality of modules, represent- 
ing portions of the application, and the pro- 
cessing unit stores only modules of said plural- 

40 ity of modules, necessary to execute the cur- 

rent portion of the application. 
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